1. Field of the Invention
Embodiments of the invention relate to naming. More specifically, embodiments of the invention relate to naming systems in which naming operations are performed locally with the results stored in non-persistent memory.
2. Background
Naming service broadly refers to the mechanism by which an object is associated with a name and by which objects may be found given their names. Each name is generated by a set of syntactic rules called, “naming convention”. An atomic name is an indivisible component of a name as defined by the naming convention. The association of the atomic name with an object is called, “binding.” Some objects cannot be stored directly so they are put in the system as references. A “reference” is an object, which contains one or some addresses of objects which themselves are not directly bound to the naming system. Every name is interpreted relative to some context, and every naming operation is performed in a context object. A “context” is a set of bindings in which names are relative to a certain naming convention. A client may obtain an initial context object that provides a starting point for resolution of names in the naming system. Every naming system consists of contexts of a certain type (one and the same naming convention) that provide the same identical set of operations. Every operation is relative to a certain namespace. A “namespace” is the set of names in the naming system. The naming service organization of the namespace is a treelike structure of naming context objects that can be traversed to locate a particular name.
A directory service is a naming service that allows each bound object to be associated with attributes and provides a way to retrieve an object by looking up some of its attributes rather than its name (search). The “attributes” are object characteristics. Both the attributes and the object itself form a directory object. A “directory” is a linked set of directory objects.
In a Java context, basic support for the naming and directory service is provided by a Java Naming and Directory Interface (JNDI) such as specified in JNDI: Java Naming and Directory Interface, Version 1.2, published by Sun Microsystems of Mountain View, Calif. and subsequent revisions thereof (the JNDI Specification). The JNDI Specification meets the system requirements of Java 2 Enterprise Edition (J2EE). These requirements are defined in the Java 2 Enterprise Edition Specification 1.3, published Jul. 27, 2001 or subsequent versions thereof (the J2EE Standard). JNDI is defined to be independent of any specific directory service implementation. This permits a variety of directories to be accessed in a common way.
Various naming services use a database management system (DBMS) service to store data resulting from naming operations. The storage within the database insures persistency of the naming operations in the event that the node goes down. One such example is depicted in FIG. 1. FIG. 1 is a diagram of a portion of naming tree and corresponding database representation used in one existing JNDI compatible naming service. The naming tree 100 shows the objects and contexts maintained in the database representation 120. As previously noted, the data is stored and managed in a database by the DBMS service. In this database representation 120, all contexts are represented as hierarchical structures of containers. As represented, the root container 102 contains the object1 container 104 and in the subcontext1 container 106. The subcontext1 container 106 contains object2 container 108 and the subcontext2 container 110. In this example, the only way to read the data 112 corresponding to object2 is by traversing through the root container 102 and then through the subcontext1 container 106 and then through the object2 container 108. In this example, since a single name space is used system wide, each naming operation must use a unique name for every object. These traversals and the required interaction with the DBMS service slow the performance of the naming service. Moreover, the stability of the naming service then also depends on the stability of the DBMS service.